The growth over the last few years in use of the World Wide Web (WWW) and the Internet by users using desktop computers has been followed by increasing use by users using mobile terminals, including wireless terminals, and, for wireless terminals, has led to the development of the wireless access protocol (WAP). Recently, new kinds of mobile devices such as pagers, cellular phones, and personal digital assistants (PDAs) all with some form of Internet browsing capability have been introduced and many more kinds of mobile devices with various browsing capabilities are under development. With so many so-called client devices (i.e. client devices of servers providing content over the Internet) of such diverse browsing capability (many with very limited capability compared to desktop computers), a server of content, called here an origin server, must take into account the sometimes limited browsing capability of a client device so that the content that is provided is appropriate for the client device in that it can be rendered intelligibly.
While there are means to tailor the content for a client device by transforming the content so that it is appropriate for the client device, before a server can carry out such a content transformation, it must know the capability of the browser hosted by the client device.
CC/PP is a WWW Consortium (W3C) working draft that addresses the exchange between a client device and an origin server of information about the browser capability of the client device asking for Content from the origin server. The browser capability information so provided is called Capability Preference Information (CPI). (See Composite Capabilities/Preference Profiles: Requirements and Architecture; W3C Working Draft 21 Jul. 2000; at http://www.w3.org/TR/CCPP-ra/ on the World Wide Web.) The so-called WAP Forum has come out with a corresponding standard, the so-called UAProf (User Agent Profile) standard, that addresses the same issues in the wireless environment. UAProf has additionally defined the capability information vocabulary specific to wireless environments and transport protocols to be employed for communicating the capability information. However, UAProf is seamlessly interoperable with CC/PP. (See the User Agent Profile specifications made available at http://www.wapforum.org/what/technical.htm on the World Wide Web.) The goal of the CC/PP framework is to specify how client devices or intermediary network elements express their capabilities and preferences (the user agent profile) to the server that originates content (the origin server). The origin server uses the “user agent profile” to produce and deliver content appropriate to the client device. In addition to computer-based client devices, particular attention is paid to other kinds of devices, such as mobile phones.
The basic problem that the CC/PP framework addresses is to create a structured and universal format for how a client device tells an origin server about its user agent profile. CC/PP provides a high level mechanism for communicating profile information and profile difference information (relative to a default profile). However, CC/PP is protocol independent, and leaves open the issue of transport protocol. The CC/PP framework describes a standardized set of CC/PP attributes, i.e. it provides a vocabulary that can be used to express a user agent profile in terms of capabilities of the client device, and also to express the user's preferences for the use of the capabilities. The framework makes use of the XML (Extensible Markup Language) application RDF (Resource Description Framework) Model and Syntax Specification for the purpose of defining client capability information. Both XML and the RDF Model and Syntax Specification are provided by W3C. This enables the framework to be flexible, extensible, and decentralized. RDF is used to express the client device's user agent profile. The client device may be a workstation, personal computer, mobile terminal, or set-top box. When used in a request-response protocol like HTTP, the user agent profile is sent to the origin server which, subsequently, produces content that satisfies the constraints and preferences expressed in the user agent profile. The CC/PP framework may be used to convey to the client device what variations in the requested content are available from the origin server. Fundamentally, the CC/PP framework starts with RDF and then overlays a CC/PP-defined set of semantics that describe profiles. The CC/PP framework specifies the RDF usage and associated semantics that should be applied to all profiles that are being exchanged.
In the wireless environment, to accommodate client devices of varying capability, various UAProf-aware elements in the WAP end-to-end architecture, such as a WAP gateway element, an HTTP Proxy element, a PPG (push proxy gateway) element, an origin server element, and a PI (push initiator) element, can perform value-added content transformation (to tailor the content to the intended client device) and then send the transformed content to the WAP client. In order to make content transformation decisions for a WAP client, the elements rely on the CPI provided to the elements by the WAP client via the UAProf or CC/PP protocol.
According to the prior art, when a UAProf (or CC/PP profile) aware client device sends (UAProf or CC/PP profile) capability profile information (i.e. a reference to the CPI for the device) to a content transformation entity/ content adaptor in the WAP end-to-end architecture, the CPI contains a superset of capability information needed by the content transformation entity; the CPI contains, for example, information on the client device hardware, software, the browser used by the client device, networking, and WAP characteristics of the client device.
As an example, consider a simple content adaptor situated on the WAP gateway providing content to a WAP client, content provided typically over the Internet by an origin server distinct from the WAP client. Since the WAP client does not understand HTML (hypertext markup language) but only WML (wireless markup language), the primary function of the gateway content adaptor here is to perform HTML to WML conversion. In order to provide a pleasant visual appearance on the client device, the gateway content adaptor needs to know about the so-called WML deck size (a parameter indicating the maximum amount of data in bytes that a WAP client is capable of receiving for WML browsing) the client device supports. Based on the WML deck size, the gateway content adaptor can split translated HTML content requested from the origin server by the WAP client device into smaller decks so that the content appears properly when seen on the requesting WAP client device, including having proper forward and backward navigation hyperlinks. The deck size is provided by the UAProf attribute named WmlDeckSize. Therefore, the adaptor needs to access the UAProf profile for the requesting WAP client device. Even though the adaptor needs to know only a single attribute, it has to parse the full UAProf profile, which might contain more than three dozen attributes.
A client provides a reference to the full CPI since it does not know what specific information is needed by the content transformation entity/content adaptor. Once a content adapter has received an RDF profile (or its URL), it can use an XML parser to compile a so-called document object model (DOM) object for the capability profile, i.e. an expression of the RDF in XML. Since a CPI typically contains a large number of attributes, the corresponding DOM object occupies a correspondingly large amount of memory in the content adapter. A full DOM tree for a client device, i.e. a DOM tree 10 corresponding to the full UAProf profile for a client device, not tailored to only what is needed by the content adaptor, is shown in FIG. 1A. The UAProf profile/DOM tree includes a root element 10a. The root element might contain one or more component elements 10b (such as WAPCharacteristics and TerminalHardware), which can themselves have one or more attributes 10c (such as the number of pixels of the video screen in two orthogonal directions, indicated by the UAProf attribute named ScreenSize), indicated as the leafs of the DOM tree 10. FIG. 1B illustrates what a reduced DOM tree 11 derived from the DOM tree 10 of FIG. 1A, i.e. the DOM tree 10 after being pared down (or filtered) so as to include only the attributes 10c needed by a content adaptor. For the gateway content adaptor discussed above, the DOM tree in FIG. 1B would be even further pared down to provide a further reduced DOM tree, containing a root node, one intermediate node corresponding to WAPCharacteristics, and one leaf node representing the ‘WmlDeckSize’ attribute.
If a full DOM object/tree were to be used once and discarded, the waste of memory would be bad enough, but DOM objects are often cached in memory for faster response in handling subsequent requests. Even if it is assumed that there are only about a hundred different UAProf profiles (covering different terminals or terminal variants), caching of the DOM objects for such a number of UAProf profiles would consume a huge amount of memory resources of the content adaptor. Additionally, the time to access a particular UAProf attribute in the full DOM tree for a client device would most likely be more than the access time for the same attribute in a filtered tree, i.e. a tree pared down to what is actually needed by the content adaptor/content transformation entity, because with a full DOM tree, some time is likely to be wasted in browsing through sibling nodes while searching for a particular attribute. Thus, the use of a full CPI/full DOM object/tree results in larger memory requirements and increases the response time needed by a content adaptor for getting UAProf attributes for a client device from a DOM object.
FIG. 2 shows the context for a scenario in which a WAP client device 20 provides CPI to an origin server 22 via a RAN 21 including a WAP gateway 21a, in accord with the prior art in the situation in which only the origin server (and not also the WAP gateway) adapts content requested by the WAP client device. In the scenario, the client device 20 first sends a message M1, communicated using WSP, requesting content from the origin server 22; the message M1 includes either a reference to the profile/CPI for the WAP client device 20 (i.e. by providing a URL for the profile) or includes a reference to a default profile and indicates the difference in the CPI for the client device 20 compared to the default profile. The request is received by the RAN (radio access network) element 21, and more specifically by the WAP gateway 21a. When the WAP gateway receives the request and the profile reference (message M1), it passes the request on to the proxy cache 21b, which then provides the request (as message M2) to the application 22a on the origin server 22. When the application 22a receives the message M2, it formulates a query based on the profile reference and passes the query (as message M3) to an XML parser 22b. The XML parser 22b then communicates the query (as message M4) to a CC/PP profile repository 24 (perhaps at least in part via the World Wide Web if the CC/PP profile repository 24 is connected to the Internet). (It is assumed here that an XML parser is capable of automatically downloading an XML file from the Internet, since the XML file must be downloaded before the XML parser can initiate parsing the XML into the DOM form. If the XML parser is not able to download by itself, then the application 22 a would have to download the profile directly, meaning that message M3 would flow from 22a to the profile repository 24 and as a result of this, application 22a would directly receive the profile. Next, the application 22a would invoke the XML parser 22b, passing it the previously downloaded profile and the parser would return (as in a called function returning a value) to the application 22a the DOM tree corresponding to the XML.)
In response to the message M4, the CC/PP repository in turn provides the requested profile information (as message M5); the profile information so provided corresponds to a full DOM tree, and so includes, in general, more information about the WAP client 20 than is needed by the application 22a to tailor its content to the WAP client 20. When the XML parser 22b receives the complete profile information for the WAP client, it parses it so as to provide a full DOM tree, and provides the full DOM tree to the application 22a (as message M6).
It is important to understand the difference between message M5 and message M6. The message M5 is a HTTP response message with the body of the message containing profile in the RDF text format. When the XML parser 22b receives the RDF(XML) text as message M5, it parses the text and starts building a tree object out of the various elements and attributes present in the RDF. Once the full DOM tree has been compiled (built), the XML parser 22b passes it back to the application 22a as message M6.
Then, the application 22a of the origin server (in message M7) provides a response, using HTTP, including the requested content, but adapted to the WAP client device 20; the proxy cache 21b receives the adapted content and provides it to the WAP gateway element 21a, which then sends the adapted content (as message MB) to the WAP client device 20 using WSP.
The prior art also allows for the WAP gateway to interface with an XML parser so as to obtain a full DOM tree for the client device 20 and so also tailor content (provided by the origin server 22 or provided by itself). In addition, the prior art allows for having only a WAP gateway interfacing with an XML parser to adapt content, instead of having an XML parser interfacing with the application 22a to adapt content either alone or in combination or in addition to a WAP gateway interfacing with an XML parser.
To address the problem of wasting memory resources by using a full DOM tree, the prior art teaches using DOM tree post processing, and, alternatively, using a global hash table. (A dictionary in which keys are mapped to array positions by a so-called hash function.) In DOM post processing, once an XML parser has parsed the RDF profile into a DOM object/tree, post processing is performed to remove at least some of the extra nodes/leafs of the DOM tree (i.e. the attributes) by making use of the DOM interface. (The W3C DOM specification provides a language and platform independent interface for accessing or manipulating XML content. A DOM parser is used to compile a DOM tree 10 (FIG. 1A) corresponding to an XML document. Each node or leaf 10c in a DOM tree is represented by a number of DOM interfaces, like ‘Node,’ which is quite generic. The different interfaces allow operations such as accessing, adding, deleting and modifying the various nodes, making it possible to prune a DOM tree. For More information about DOM, refer to http://www.w3c.org/DOM/)
A variant of the DOM tree post processing approach is to reduce the RDF/XML to desired form using XSLT (extensible stylesheet language, transformation part), a specification for converting a document from one type/schema to another, consisting of a set of rules that describe exactly how and where a piece of content in a first document type should appear in a second document type, rules that are described in XML themselves, or in other words, a language for specifying how to transform an XML document of one type to another type. After the XLST processing is complete, an XML parser is invoked to compile the reduced RDF into the DOM object.
Another implementation approach that can be adopted by content adaptors is to use selected attributes in a hash table. In this approach, the RDF profile is first parsed into a (normal) DOM tree object. Then the relevant UAProf attributes are retrieved and added to a global hash table or to an individual hash table corresponding to a given profile. The hash table is used thereafter, instead of the DOM tree.
The above implementations are all in accord with the CC/PP framework and UAProf specification, because the CC/PP framework and UAProf specification describe the transport, format and attribute vocabulary for a CPI but leave open how to read and update profiles, i.e. how an entity inside a WAP end-to-end chain reads and updates profiles is not specified. However, when an entity communicates with another entity, the communicated profile must be in RDF format to be in accord with the CC/PP framework and UAProf specification.
What is needed is a more efficient mechanism for providing, for a client device, a DOM object/tree including only the attributes needed by an origin server, or any other intermediary element that serves as content adaptor, in providing content to the client device.